Chapter 9
Building Cube Systems Through Composition
"The Cube Framework does not build large systems. It builds small systems that collaborate."
Why This Chapter Exists
Every Cube module follows the same architectural philosophy.
Whether assembling a weapon, configuring a vehicle or creating a custom character, the framework avoids constructing large monolithic objects.
Instead, every runtime system is built from smaller independent parts.
This decision was made deliberately.
Not because inheritance is inherently wrong.
But because composition aligns more naturally with the architectural goals of the Cube Framework.
The Cube Perspective
The Cube Framework views every runtime object as an assembly of capabilities rather than a predefined type.
A weapon is not defined solely by being a weapon.
It is defined by the capabilities it possesses.
Can it fire?
Can it reload?
Can it replicate?
Can it own attachments?
Can it receive modifications?
Each capability represents an independent responsibility.
The runtime object simply becomes the place where these responsibilities collaborate.
Capabilities Instead of Hierarchies
Traditional object-oriented design often starts by asking:
"What is this object?"
The Cube Framework asks a different question.
"What should this object be capable of doing?"
This small shift changes the entire architecture.
Instead of creating increasingly deep inheritance hierarchies, the framework assembles runtime objects from independent systems that each contribute a specific capability.
The result is an architecture that naturally adapts as new requirements emerge.
Composition Preserves Responsibilities
One of the core principles introduced earlier in this handbook is that every subsystem should own a single responsibility.
Composition supports this principle naturally.
Each participating system performs one clearly defined task.
No capability needs to understand every other capability.
Instead, collaboration occurs through clearly defined architectural boundaries.
Responsibilities remain isolated.
The runtime object becomes the meeting point rather than the owner of every behavior.
Extending Without Rebuilding
One of the primary goals of the Cube Framework is long-term extensibility.
New gameplay features should rarely require rewriting existing runtime objects.
Instead, new capabilities should integrate alongside existing ones.
A future vehicle module may introduce completely different runtime components than a weapon.
A character module may assemble an entirely different collection of capabilities.
Despite these differences, every module follows the same architectural philosophy.
Composition allows this consistency without forcing identical implementations.
Runtime Assembly Makes Composition Practical
Composition alone is not sufficient.
The Cube Framework combines composition with Runtime Assembly.
Definitions describe which capabilities belong together.
Runtime Assembly constructs the final runtime representation.
This means that runtime objects are not manually handcrafted.
They are assembled from authored knowledge.
Composition therefore becomes a consequence of the framework rather than an implementation detail.
Building a Framework Instead of Features
Choosing composition is not merely a technical decision.
It reflects the purpose of the Cube Framework itself.
Frameworks should make future systems easier to build.
Composition allows entirely new modules to reuse architectural concepts without inheriting implementation details from unrelated systems.
The architecture remains recognizable.
The implementations remain independent.
Design Note
When introducing a new runtime capability, avoid asking:
"Which existing class should own this?"
Instead ask:
"Does this represent a new architectural responsibility?"
If the answer is yes, it likely deserves its own independent capability.
Framework Law IX
Cube systems grow by composition, not accumulation.
Every new capability should strengthen the architecture without increasing the responsibility of existing systems.
Looking Ahead
Composition explains how Cube assembles runtime systems.
The next chapter explores a broader question.
What actually makes the Cube Framework a framework?
Understanding this distinction explains why the architecture remains consistent across every future Cube module.
Revision History
Version 1.0
Initial publication.